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(54) Universelle Bewegungssteuerung 

(57) Die in einer universeilen Bewegungssteuerung 
UMC bendtigten Parametrierinformationen (Beschrei- 
bungen von Systemvariablen, Alarmen und Sprachbe- 
fehlen) werden uber einen zentralen Umsetzer (U) aus 
einer einheitlichen Beschreibungssprache generiert 
und an Engineering-System (ES1-ES4), Run-Time-Sy- 
stem (RTS1-RTS4) sowie Ausgabemedien (AM) fur die 



Dokumentation verteilt. Dadurch ist gewahrleistet, daf3 
die Parametrierdaten fur alle Systemteile konsistent 
sind. Daruberhinaus konnen auch Konfigurierinforma- 
tionen (FWK) von Technologiepaketen (TP) uber den 
Umsetzer U ins Engineering- (ES1-ES4) und ins Run- 
Time-System (RTS1-RTS4) der Steuerung gebracht 
werden. 
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Beschreibung 

[0001 ] Die Erfindung bezieht sich auf eine universelle Bewegungssteuerung mit Engineering- unci Run-Hme-System , 
welche funktionell die klassischen Aufgaben einer speicherprogrammierbaren Steuerung und einer numerischen 

5 Steuerung in sich vereinigt. 

[0002] Es ist heutzutage ublich, sowohl fur die speicherprogrammierbare Steuerung als auch fur die Bewegungs- 
steuerung jeweils unterschiedliche hierarchische Ablaufebenen zu modellieren, denen Software-Tasks zur Steuerung 
des jeweiligentechnischen Prozesses zugeordnet werden. Diese Tasks konnen Systemaufgaben erfullen, sie konnen 
aber auch anwenderprogrammiert sein. 

w [0003] Es ist bekannt, daB bei einer speicherprogrammierbaren Steuerung "SPS", also auch bei einer Bewegungs- 
steuerung "NC", Anwenderprogramme bzw. vom Anwender erstellte Tasks in den Speicher der jeweiligen Steuerung 
zugeladen und zur Ausfuhrung gebracht werden konnen. 

[0004] Aus der DE 1 97 40 550 A1 ist es bekannt, daB ProzeBsteuerungsfunktionalitaten der speicherprogrammier- 
baren Steuerungen "SPS" und Bewegungsfunktionalitaten von NC-Steuerung in einem einheitlichen konfigurierbaren 

'5 Steuerungssystem integriert werden konnen. 

[0005] Diese SPS/NC-lntegration geschieht in Form des Zusammenschaltens von SPS- und NC-Steuerungsbau- 
gruppen. Bei einer solchen Ausfuhrung der Integration wird aber keine optimale und effiziente Taskstruktur fiir die 
Gesamtheit der Steuerungsaufgaben erreicht. AuBerdem kann bezuglich der ProzeGsteuerung, also auch bezuglich 
der Bewegungssteuerung, erweiternde Funktionalitat nur in Form von Anwenderprogrammen nachgeiaden und zur 

20 Ausfuhrung gebracht werden. 

[0006] Es ist heutzutage ublich, Steuerungen mit Parametrierinformationen zu versorgen. 
[0007] Parametrierinformationen umfassen in diesem Zusammenhang 

die Beschreibung von Systemvariablen mit Datentyp, Attributen und Beschreibungstexten, 
25 - die Beschreibung von Alarmen, mit ihrem strukturellen Aufbau, Attributen und Alarmtexten, sowie 

die Beschreibung von Sprachbefehlen (Bewegungs- und Technologiebefehle) mit Syntax und dazugehorigen Pa- 
rameters 

[0008] Ublicherweise werden aber diese Parametrierinformationen, die an unterschiedlichen Stellen innerhalb der 
30 Steuerung benotigt werden, jeweils separat an diesen Stelien in der Steuerung implementiert. Die Konsistenz dieser 
verteilt implementierten Parametrierinformationen ist nursehr aufwendig sicherstellbar. 

[0009] Der Erfindung liegt daher die Aufgabe zugrunde, fiir jeweils unterschiedliche Steuerungsaufgaben und un- 
terschiedliche Randbedingungen bzw. Anforderungen des zugrundeliegenden technischen Prozesses in einfacher 
Weise optimale Auspragungen der kombinierten SPS/NC-Steuerungen sowohl hinsichtlich ihrer Steuerungsstruktur 
35 als auch hinsichtlich ihrer Funktionalitat zu erstellen und dabei sicherzusteilen, daB die in der Steuerung implemen- 
tierten Parametrierinformationen immer konsistent zueinander sind. 

[0010] GemaB der Erfindung wird diese Aufgabe dadurch gelost, daB ein einheitltches Ablaufebenenmodell derge- 
stalt gebildet ist, daB es mehrere Ablaufebenen unterschiedlichen Typs mit unterschiedlicher Prioritat aufweist, wobei 
von hochster bis niedrigster Prioritat verschiedene Anwender- und Systemebenen vorgesehen sind und daB jeweils 

40 Technologiepakete anwenderseitig in das Engineering- und/oder Run-Time-System ladbar sind, daB eine Datenquelle 
fiir Beschreibungsinformationen fur Systemvariablen sowie gegebenenfalls Alarme und/oder Sprachbefehle uber einen 
Umsetzer dem Engineering-System Sprachbefehle und/oder Systemvariablen zur Verfugung stellt, daB aus dem Run- 
Time-System die Systemvariablen mit aktuellen Daten des technischen Prozesses versorgbar sind und daB uber eine 
Bedienoberflache des Engineering-Systems weitere Eingaben anwenderseitig machbarsind. 

45 [0011] Ein wesentlicherVorteil der Erfindung liegt darin, daB die Parametrierinformationen der Steuerung, die sowohl 
im Engineering-System, im Run-Time-System, aber auch fur die Dokumentation und eine etwaige Testautomatisierung 
benotigt werden, immer konsistent sind. Der Umsetzer, der an zentraler Stelle die Parametrierinformationen fur die 
Dokumentation, das Engineering-System und das Run-Time-System aufbereitet und verteilt, kann ohne groBen Auf- 
wand Semantikchecks durchfuhren. Auch konnen OEM (Original Equipment Manufacturer)-Kunden in dieser Daten- 

50 quelle fur Beschreibungsinformationen, d.h. an definierter Stelle, aufwandsarm weitere Parametrierinformationen fur 
die Steuerung erstellen und in die Dokumentation einbringen. 

[0012] Ein weiterer Vorteil der Erfindung liegt darin, daB innerhalb der Ablaufebenen die Tasks der Steuerung so 
angeordnet werden konnen, daB der Kommunikationsaufwand innerhalb der Steuerung reduziert wird, 
[0013] Ein weiterer Vorteil liegt darin, daB anwenderseitig durch dieZuladung von Technologiepaketen in das Engi- 
55 neering- und/oder Run-Time-System der Steuerung eine anwendungsspezifische Skalierung des Run-Time-Systems 
der Steuerung bezuglich ihrer Funktionalitat erreicht werden kann. 

[0014] Eine erste vorteilhafte Ausgestaltung der Erfindung liegt darin, daB vom Umsetzer aus dem Bestand der 
Datenquelle relevante Dokumentationsinformationen an ein Ausgabemedium weiterleitbar sind. Dadurch wird sicher- 
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gestellt daB alle Dokumentationsinformationen aus einer gemeinsamen Datenquelle stammen und somit immer un- 
tereinanderkonsistentsind, unabhangig, auf welches Ausgabemedium (z.B. DruckeroderOnline-Hilfe) die Dokumen- 
tationsinformation ausgegeben wird. . 
[0015] Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, daB als Ablaufebenen vorgesehen sind: 

5 

a) eine Lagereglerebene, bestehend aus zugehoriger getakteter Systemebene und Anwenderebene, 

b) eine Interpolatorebene, bestehend aus zugehoriger getakteter Systemebene und Anwenderebene, 
io c) eine Event-Systemebene fur reaktionspflichtige Ereignisse, 

d) eine Anwenderebene fur asynchrone Fehler, 

e) eine weitere, vom Anwender anforderungsspezifisch frei projektierbare Anwenderebene fur Alarm- und/oder 
is Event- und/oder Regelungs- und/oder sonstige zyklische Tasks, 

U cine aus der Abfolge von Bewegungssequenzen, freien Zyklen und niederprioren sonstigen Systemtasks, ge- 
bildeie Ebenengruppe fur Hintergrund-Bearbeitung, 

20 wobei die Ablaufebenen a bis e eine Ebenengruppe fur Echtzeit-Bearbeitung bilden. 

[0016] Ein wesentiicher Vorteil dieser Schichtung liegt darin, da(3 die Kommunikation zwischen den Tasks der Pro- 
zeBsteuerung und denen der Bewegungssteuerung minimiert wird. Dadurch kann die Programmierung der Steue- 
rungsaufgaben fur die ProzeBsteuerung und fur die Bewegungssteuerung in einer einheitlichen Programmiersprache 
mit cincr einheitlichen Erstelloberflache erfolgen. 

25 [0017] Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, da3 die Technologiepakete beinhalten: 

a) Code-Teile, die die Regelungsspezifika fur das Run-Time-System reprasentieren und 

b) einen Konfigurierteil der die Zuordnung dieser Code-Teile zu den jeweiligen Systemebenen, sowie deren Be- 
30 arbeitungsfolge aufweist, wobei 

c) bedarfsweise diese Informationen des Konfigurierteiis auch an das Engineering-System weiterleitbar sind. 

[0018] Somit ist es moglich, da3 der Anwender durch dynamisches Zuladen solcher Technologiepakete die M6g- 

35 lichkeit einer technologischen Skalierung des Run-Time-Systems der Steuerung besitzt. Damit kann der Anwender 
ausgehend von einem Basissystem der Steuerung den Befehlsvorrat dieses Basissystems bzw. Betnebssystems dy- 
namisch zugeschnitten auf die jeweiligen Erfordernisse des zugrundeliegenden technologischen Prozesses oder der 
Steuerungsaufgabe erweitern. Der Anwender hat somit die Moglichkeit, die vorhandene Grundfunktionalitat einer 
Steuerung gezielt urn solche Funktionalitaten zu erweitern, die er wirklich fur seine Anwendungen benotigt. Das Ba- 

40 sissystem bildet hierbei den Auslieferungsumfang des Run -Time-Systems einer Steuerung, namlich em Echtzeitbe- 
triebssystem ein Ablaufsystem (mit System- und Anwenderebenen), Tech nologieobjektty pen, Sprachbefehle, den 
SPS-Befehlsvorrat sowie Kommunikations- (z.B. LAN : E/A) und technologische Schnittstellen (z.B. Antnebe, Geber) 
zum technischen Prozef3. Im Basissystem befindet sich somit die notwendige Grundfunktionalitat einer Steuerung. 
Das Basissystem ist dabei auf unterschiedlichsten HW-Plattformen (z.B. PC, Antrieb, ...) ablauffahig. 

45 [0019] Dadurch, daB die Informationen des Konfigurierteiis einesTechnologiepaketes uber die Datenquelle und den 
Umsetzerins Run -Time-System und ins Engineering-System gebracht werden, lassen sich Parametrier- und Konfigu- 
rierinformationen in einheitlicher Weise in die Steuerung einbringen und ein Anwender kann an zentraler Stelle Ande- 
rungen in den Parametrier- bzw, Konfigurierdaten vornehmen. Die sogenannten Parametrierinformationen entspre- 
chen Datenbeschreibungen fur ubliche und generelle Steuerungsaspekte, namlich Systemvariablen, Alarmen und 

so Sprachbefehlen. Die Konfigurierinformationen beziehen sich hingegen auf Technologiepakete und damit auf d»e Mog- 
lichkeit einer technologischen Skalierung einer Steuerung. 

[0020] Dadurch, daB jedes Technologiepaket eine angepaBte Anzahl von Technologieobjekttypen fiir das Run-Time- 
System beinhaltet, ist es moglich, auch komplexe und anspruchsvolle Steuerungsfunktionalitaten in einer ubersichtli- 
chen und verstandlichen Form dem Run -Time-System zuzuladen. 
55 [0021] Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, daB des weiteren Bedienoberftacheninfor- 
mationen, insbesondere Bedienparameter, und/oder Sprachmechanismen und/oder Deklarationsteile den Code-Teilen 
■^zuweisbarsind. 

[0022] Dadurch ergeben sich folgende Vorteile: 
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[0023] Um einen Technologieobjekttyp nicht nur als nicht mehr anderbare Konstante verwenden zu konnen, muB 
der Technologieobjekttyp dem Erstellsystem die Moglichkeiten der Parametrierung fur seine instanziierten Technolo- 
gieobjekte und insbesondere die vorhandenen Bedienparameter bekanntmachen. Damit hat ein Anwender die Mog- 
lichkeit, ein Technologieobjekt in der Oberflache des Erstellsystems flexibel zu parametrieren. 
5 [0024] Dadurch, daB auch Sprachmechanismen zuladbar sind, ist es moglich, daB dynamisch der Befehlsvorrat des 
Run-Time- Systems erweitert werden kann. In einem Anwenderprogramm kann der Anwender einen solchen zugela- 
denen Befehl in der Form verwenden, als ware er ein Befehl der Grundfunktionalrtat. 

Wenn ein Anwenderprogramm mit einem solchen zugeladenen Befehl innerhalb einer Anwenderebene des Ablaufe- 
benenmodells abgearbeitet wird, wird bei Aufruf dieses zugeladenen Befehls die dazugehorige Codesequenz des 
10 Betriebssystems auf einer der Systemebenen des Ablaufebenenmodells abgearbeitet. Dies geschieht ohne Zutun des 
Anwenders. Durch die Zuordnung von Deklarations- und Beschreibungsteiien zu den Code-Teilen des Technologie- 
paketes wird die Flexibility fur den Anwender weiterhin erhoht. 

[0025] Ein Ausfuhrungsbeispiel der Erfindung ist in der Zeichnung dargestellt und wird im folgenden erlautert. 
[0026] Dabei zeigen: 



15 



20 



25 



30 



35 



FIG 1 die Steuerung eines technischen Prozesses mit getrennter speicherprogrammierbarer Steuerung und Bewe- 
gungssteuerung. Die Programmierung erfolgt uber jeweils separate Programmiersysteme, 

FIG 2 die wesentlichen Ablaufebenen einer klassischen speicherprogrammierbaren Steuerung, 

FIG 3 die wesentlichen Ablaufebenen einer Bewegungssteuerung, 

FIG 4 eine universelle Steuerung, d.h. eine kombinierte SPS/NC-Steuerung mit einem dazugehdrigen Program- 
miersystem, 

FIG 5 das Ablaufebenenmodell der universellen Steuerung, 

FIG 6 zeigt als O0(objektorientiert)-Strukturdiagramm ein Technologiepaket, bestehend aus Code-Anteil, Parame- 
ter, Firmware-Konfiguration, Technologieobjekttyp, Sprachkomponente und Dekfarationsteil, 

FIG 7 zeigt als OO-Strukturdiagramm Technologieobjekttypen fur das Technologiepaket Kunststoff und 

FIG 8 zeigt wie aus einer Datenquelle die Beschreibungsbzw. Parametrierinformationen uber einen Umsetzer dem 
Engineering-System, dem Run-Time-System und einem Ausgabemedium zur Verfugung gestellt werden. 



[0027] In der Darstellung gemaB FIG 1 wird, in Form eines Strukturbildes gezeigt, daB zur Steuerung eines techni- 
schen Prozesses TP1 ein paralleler Betrieb einer speicherprogrammierbaren Steuerung SPS und einer Bewegungs- 
steuerung NC stattfindet. Speicherprogrammierbare Steuerung SPS und Bewegungssteuerung NC enthalten jeweils 
ein Run -Time-System RTS1 bzw. RTS2. Die Kommunikation zwischen den beiden Steuerungen erfolgt uber spezielle 

40 Hilfsmittel, exemplarisch dargestellt ist ein bidirektionaler Kommunikationskanal K. Die Programmierung der Steue- 
rungen durch den Anwender erfolgt in der Regel in unterschiedlichen Programmiersprachen mit unterschiedlichen 
Erstell oberflache n. Das heiBt, durch jeweils separate Programmier- oder Engineering-Systeme P1 , ES1 und P2, ES2. 
Der wesentliche Nachteil dieser konventionellen Ausfiihrung liegt zum einen in der aufwendigen Kommunikation zwi- 
schen den beiden Steuerungen, zum anderen in den separaten und unterschiedlichen Programmier- bzw. Engineering- 

45 Systemen P1 , ES1 und P2, ES2. Uber Ein- und Ausgange EA1 , EA2 der Steuerungen wird der eigentliche technische 
ProzeB TP1 gesteuert. Zwischen dem Programmiersystem P1 und der speicherprogrammierbaren Steuerung SPS 
bzw. zwischen dem Programmiersystem P2 und der numerischen Steuerung NC befinden sich Informationspfade 11 
bzw. 12, auf denen die Programme in die jeweilige Steuerung geladen werden. 

[0028] In der Darstellung gemaB FIG 2 sind die wesentlichen Ablaufebenen einer klassischen speicherprogrammier- 
so baren Steuerung (SPS; FIG 1), angeordnet nach ihrer Prioritat, gezeigt. Der Prioritatsanstieg ist dabei durch einen 
Pfeil symbolisiert. In der niederpriorsten Ebene werden, wie durch eine gestrichelte Linie angedeutet, zwei unterschied- 
liche Aufgaben, namlich ein freier Zyklus, d.h. "Anwenderebene freier Zyklus" und eine Hintergrund-Systemebene, d. 
h. "Systemebene Hintergrund", im Round-Robin-Verfahren, also zeitscheibengesteuert, abgewickelt. Der Hintergrund- 
Systemebene sind z.B. Kommunikationsaufgaben zugeordnet. Bei einer folgenden getakteten Anwenderebene, be- 
55 zeichnet als "Anwenderebene getaktet", ist der Aufruftakt derTasks bzw. der Programme dieser Ebene parametrierbar. 
Es erfolgt eine Uberwachung dahingehend, ob die Bearbeitung eines Anwenderprogrammes dieser getakteten Ebene 
rechtzeitig abgeschlossen ist, bevor das Startereignis erneut auftritt. Lauft die Taktzeit ab, ohne daB das Anwender- 
programm derzugeordneten Ebene fertig abgearbeitet ist, wird eine entsprechende Task einer prioritatsmaBig uber- 
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nachsten "Anwenderebene fur asynchrone Fehler" gestartet. In dieser "Anwenderebene fur asynchrone Fehler" kann 
der Anwenderdie Behandlung von Fehlerzustanden ausprogrammieren. 

[0029] Auf die "Anwenderebene getaktet" folgt eine "Anwenderebene Events". Die Reaktion auf externe oder interne 
Ereignisse (Events) erfolgt innerhalb der "Anwenderebene Events". Ein typisches Beispiel fur ein solches Ereignis ist 
5 das Uberschreiten eines Grenzwerts. In einer "Systemebene hochprior" liegen Aufgaben des Betnebssystems, welche 
die Arbeitsweise der speicherprogrammierbaren Steuerung sicherstellen. 

[0030] Die Darstellung gemaB FIG 3 zeigt die wesentlichen Ablaufebenen einer Bewegungssteuerung (NC; FIG 1). 
Auch hierbei sind die einzelnen Ebenen nach ihrer Prioritat hierarchisch, wie durch einen Pfeil symbolisiert, angeordnet. 
Eine "Systemebene Hintergrund" und eine "Anwenderebene sequenziell" haben eine gleiche Prioritat, namhch die 

10 niedrigste Diese aufgabenmaBige Zusammengehdrigkeit ist wie bei FIG 2 durch eine gestrichette Lime symbolisiert. 
Die Tasks der "Anwenderebene sequenziell" werden zusammen mit den Tasks der "Systemebene Hintergrund" im 
Round-Robin-Verfahren abgearbeitet. Typische Tasks der "Systemebene Hintergrund" sind z.B. solche fur Kommuni- 
kationsaufgaben. In der "Anwenderebene sequenziell" laufen die vom Anwender programmierten Programmteile fur 
die eigentliche Steuerungsaufgabe. StoBt die Steuerung in einem dieser Programmteile auf einen Bewegungs- oder 

15 Positionierbefehl, wird ein Suspend gesetzt, d.h. das Anwenderprogramm wird an dieser Stelle unterbrochen. Die 
Abarbeitung dieses Bewegungs- oder Positionierbefehls geschieht in einer hochstprioren "Systemebene getaktet". Em 
jeder Lageregler, der in der "Systemebene getaktet" ablauft, fuhrt diesen Bewegungsbzw. Positionierbefehl aus. Nach 
Ausfuhrung des Befehls wird in die "Anwenderebene sequenziell" zuruckgesprungen und das durch Suspend unter- 
brochene Anwenderprogramm wird durch ein Resume an der gleichen Stelle fortgesetzt. Die "Systemebene getaktet" 

20 enthalt neben den schon erwahnten Lagereglern auch den Interpolationsteil der Steuerung. 

[0031] Auf die niederphorste Ebene setzt eine "Anwenderebene getaktet" auf. Hier laufen zyklische Tasks ab, z.B. 
Reglerfunktionalitaten. 

[0032] In einer folgenden "Anwenderebene Events" sind solche Tasks untergebracht die auf externe oder interne 
Ereignisse reagieren. Solche Ereignisse konnen beispielsweise Aiarme sein. 

25 [0033] In der Darstellung gemaB FIG 4 wird ein technischer ProzeB TP2 durch eine kombinierte SPS/NC-Steuerung 
UMC gesteuert. Das Akronym UMC steht fur UNIVERSAL-MOTION-CONTROL. Die Verbindung zwischen der Steue- 
rung UMC und dem zugehorigen technischen ProzeBTP2 geschieht bidirektional uber Ein-/Ausgange EA3. Die Pro- 
grammierung der kombinierten SPS/NC-Steuerung geschieht iiber ein gemeinsames Programmier- P3 oder Enginee- 
ring-System ES3, wobei das Engineering-System ES3 ebenso wie bei FIG 1 eine komfortable Oberflache fur das 

so Programmiersystem P3 zur Verfugung stellt. Die damit erstellten Programme werden uber einen Informationspfad 13 
in ein Run-Time-System RTS3 der universellen Bewegungssteuerung UMC ubertragen. Die Darstellung gemaB FIG 
5 zeigt das Ablaufebenenmodell der universellen Bewegungssteuerung. Die Priorisierung der Ebenen wird wie im 
vorangegangenen durch einen Pfeil in Richtung zur hochsten Prioritat angedeutet. Die niederphorste Ebenengruppe 
ist die sogenannte "Ebenengruppe Hintergrund-Bearbeitung". Sie besteht aus einer "Systemebene Hintergrund", aus 

35 einer "Anwenderebene freier Zyklus" und aus einer "Anwenderebene sequenziell". Die Tasks dieser drei gleichpnoren 
Ebenen (angedeutet durch die gesthchelten Grenzlinien) werden zyklisch im Round-Robin-Verfahren abgearbeitet. 
Eine auf die "Ebenengruppe Hintergrund-Bearbeitung" hoherphor folgende "Ablaufebene" ist eine vom Anwender an- 
forderungsspezifisch frei projektierbare Anwenderebene FA, durch doppelte Umrandung gekennzeichnet, fur Alarm- 
und/oder Event- und/oder Regelungs- und/oder sonstige zyklische Tasks. Diese Anwenderebene FA besteht somit 

40 explizit aus vier Typen von Ebenen, die wiederum hinsichtlich ihrer Prioritaten innerhalb der Anwenderebene FA vom 
Anwender staffelbar sind. 

Typ 1 : Anwenderebene Event 

45 Typ 2: Anwenderebene Alarm 

Typ 3: Anwenderebene getaktet 

Typ 4: Systemebene parametriert 



50 



55 



[0034] Ebenen dieser Typen konnen vom Anwender frei wahlbar innerhalb der Anwenderebene FA, mit jeweils zu- 
grundegelegten, vom Anwendervergebbaren Prioritaten, angeordnet werden. Damit hat der Anwenderdie Moglichkeit, 
eine den Anforderungen und Randbedingungen der Steuerungsaufgabe und des zu steuernden technischen Prozes- 
ses optimaie Auspragung der universellen Bewegungssteuerung zu erreichen. 

[0035] In der "Anwenderebene Event" sind z.B. Tasks angeordnet, die auf Eingange der Peripherie reagieren. In der 
"Anwenderebene Alarm" sind z.B. Tasks angeordnet, die auf Grenzwertuberwachungen reagieren. In der "Anwende- 
- rebene getaktet" sind zyklische an wenderprogrammierbare Tasks enthalten. In die "Systemebene parametriert" konnen 
von auBen zuladbare Programme integriert werden. Dadurch ist esmoglich, daBdie universelle Bewegungssteuerung 
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dynamisch um zusatzliche technologische Funktionalitaten erweitert werden kann. In diese "Systemebene parame- 
triert" werden ublicherweise Tasks fur langsame Regelungs- bzw. Uberwachungsaufgaben (z.B. Aufgaben mitZyklus- 
zeiten im Bereich von 100 ms) zugeladen. 

[0036] Die nachsthdherpriore Ebene im Ablaufebenenmodell der universellen Bewegungssteuerung ist eine "An- 
wenderebene fur asynchrone Fehler". In dieser Ebene kann der Anwender, ahnlich wie bei einer speicherprogram- 
mierbaren Steuerung, die Behandlung von Fehlerzustanden ausprogrammieren. In der "Anwenderebene fur asynchro- 
ne Fehler" sind z.B. Tasks angesiedelt, die auf technologische Alarme reagieren. Der Anwender hat auch die Moglich- 
keit, innerhalb dieser "Anwenderebene fur asynchrone Fehler" eine fur die Produktauspragung spezifische Anzahl von 
Ebenen zu parametrieren. Der Ubersichtlichkeit halber sind Einzelheiten hierzu in der Darstellung nicht gezeigt. Der 
Anwender kann somit bedarfsweise bestimmten Fehlerereignissen eine bestimmte Prioritat zuordnen. 
[0037] Als nachstes folgt die "Event-Systemebene". Die Tasks der "Event-Systemebene" reagieren auf kritische 
interne oder externe Ereignisse, wie z.B. Nothalt. 

[0038] Die nachste Ebene ist eine "Interpolatorebene". Sie enthalt eine "getaktete Systemebene" und eine "Anwen- 
derebene". 

[0039] Die hochstpriore Ebene ist die "Lagereglerebene". Auch sie enthalt eine "getaktete Systemebene" und eine 
"Anwenderebene". Die Anwenderebenen der Lageregler- und Interpolatorebene enthalten Tasks, die im Lageregler- 
b/w Inierpolatortaktaufgerufen werden. Die Laufzeit dieser Tasks wird uberwacht, das Uberschreiten einer durch das 
System festgelegten Zeit fuhrt zum Abbruch der Ebene und zum Auslosen eines asynchronen Fehlers in der "Anwen- 
derebene fur asynchrone Fehler". 

[0040] Der Lageregler hat eine hohere Prioritat als der Interpolator, d.h. der Lageregler kann nicht vom interpolator 
unterbrochen werden, wobei der Lageregler aber den Interpolator unterbrechen kann. 

[0041] Im Ablaufebenenmodell der universellen Bewegungssteuerung konnen prinzipiell innerhalb der einzelnen 
Ablaufebenen neben den bereits erwahnten, weitere priorisierende Schichtungen vorgesehen sein. 
[0042] Die Darstellung gemaB FIG 6 zeigt als OO-Strukturdiagramm, wobei die Kardinalitaten durch eine gangige 
Ziffem-Notation angezeigt werden, ein Technologiepaket TP mit seinen Bestandteilen: 

a) Ablauffahige Code-Teile (Code) 

b) Parameter (PAR) 

c) Firmware-Konfiguration (FWK) 

d) Mindestens einem Technologieobjekttyp (TO) 

e) Sprachmechanismen (SPR) 

f) Deklarations- und Beschreibungsteil (ACC) 

[0043] Die 1 bis n Code-Teile (z.B. C-Funktionen) werden beispielsweise fur die Bewegungsfuhrung oder die Lage- 
regelung oder fur eine andereTechnologie verwendet. Die Code-Teile konnen unteranderem Befehle fur Temp eratur- 
fiihrung, Temperaturregelung oder fur spezielle Technologien wie z.B. Pressen oder Kunststoffverarbeitung beinhalten. 
Wie diese Code-Teile im Ablaufebenenmodell der Steuerung in die Systemebenen eingehangt werden und in weicher 
Reihenfolgesie zur Abarbeitung, d.h. Ausfuhrung, gelangen sollen, wird in der Firmware-Konfiguration FWKfestgelegt. 
In dieser steht also die Information, in welche Systemebene ein Code-Teil integriert werden soil und wenn in einer 
Systemebene mehrere Code-Teile integriert sind, in weicher Reihenfolge diese Code-Teile abgearbeitet werden sollen. 
[0044] Der Parameter-Teil PAR beinhaltet Oberflachen- und Bedienparameterfurdas Engineering-System (ES; FIG 
1 , FIG 4, FIG 8) als auch die Mechanismen fur das Run-Time-System (RTS; FIG 1, FIG 4, FIG 8), die eine Parame- 
trierung ermoglichen. Damit hat der Anwender die Moglichkeit, Instanzen von Technologieobjekttypen TO eines Tech- 
nologiepaketes TP gemaB seinen Anforderungen zu parametrieren. 

[0045] Mit Hilfe der 1 bis n Sprachmechanismen SPR eines Technologiepakets TP laBt sich der Sprachvorrat des 
Engineering-Systems (ES; FIG 1, FIG 4, FIG 8) um Befehle und Operatoren, die fur das zugrundeliegende Technolo- 
giepaket TP mit seinen zugehorenden 1 bis n Technologieobjekttypen TO adaquat und sinnvoll sind, erweitern. Sprach- 
mechanismen SPR mussen ins Engineering-System (ES; FIG 1 , FIG 4, FIG 8) und ins Run-Time-System (RTS; FIG 
1 , FIG 4, FIG 8) der Steuerung geladen werden. Nachdem solche Sprachmechanismen (z.B. "erhohe Temperatur") 
im Engineering-System (ES; FIG 1 , FIG 4, FIG 8) installiert wurden, sind sie im Compiler und in der Oberflache bzw. 
im Browser des Engineering-Systems (ES; FIG 1, FIG 4, FIG 8) bekannt und konnen vom Anwender in seinen An- 
wenderprogrammen direkt verwendet werden. Durch eine Plug & Play-Technologie wird sichergestellt, daB im Engi- 
neering-System (ES; FIG 1 , FIG 4, FIG 8) bekannte Sprachmechanismen auch als ablauffahiges Codestuck im Run- 
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Time-System (RTS- FIG 1 FIG 4, FIG 8) vorhanden sind. Der Anwender verwendet also die Spezifikation der Sprach- 
mechanismen, urn die Implementierung im Run-T.me-System (RTS; FIG 1 , FIG 4, FIG 8) braucht er sich nicht mehr 
zu kummern. In der spater noch behandelten FIG SwirddasZusammenspiel von Zuladen, Verwenden und Abarbeiten 
von Sprachmechanismen SPR von Technologiepaketen TP genauer erlautert werden. 

5 [0046] Zuriick zu FIG 6: In der ACC-Komponente eines Technologiepakets TP befindet sich die Beschreibung aller 
Sprachelemente, die das Technologiepaket TP enthalt, die Beschreibung aller Systemvariablen und aller Typen, die 
im TechnologiepaketTP verwendet werden. Die ACC-Komponente entspricht somit einem Deklarations- und Beschrei- 
bungsteil fur das Technologiepaket TP. Diese ACC-Komponente wird in erster Linie ins Run-Time-System (RTS; FIG 
1 FIG 4 FIG 8) derSteuerung geladen. Dadurch wird sichergestellt, daB sich alle Informationen bzgl. vorhandener 

w Technologiepaketen TP und Technologieobjekttypen TO im Run-Time-System der Steuerung befinden und somit der 
AnschluG von Bedien- und Beobachtungsgeraten (z.B. Operator Panels) sehr leicht moglich ist. 
[0047] Nachfolgende Tabelle zeigt, wohin die Bestandteile des Technologiepakets TP innerhalb der Steuerung ge- 
laden werden: entweder ins Engineering-System (ES; FIG 1, FIG 4, FIG 8) Oder ins Run-Time-System (RTS; FIG 1, 
FIG 4, FIG 8) odersowohl ins Engineering-System (ES; FIG 1, FIG 4, FIG 8) als auch ins Run-Time-System (RTS; 

15 FIG 1, FIG 4, FIG 8). 



Bestandteil ; 


TP- . 

Kompo- 

nente 


wird 

geladen 

in: 


ablauffahiqer Code 


Code 


RT 


Parametrieroberflache (und entsprechendes Wissen uber die einzemen pa- 
rameter) . _ 


PAR 


ES 


Konfigurations-informationen 

(Informationen, wie und wo die Teile in das Ablaufsystem einqeklinkt werden) 


FWK 


ES + RT 


Anwenderschnittstelle (Befehte (MOVE, POS, ...), SFCs, SFBs, Systemvari- 
ablen, ...) 


SPR 


ES + RT 


Anwenderschnittstelle (qraphische Informationen) 


SPR 


ES 


Beschreibunqsinformationen fur Systemvariablen, Alarme, ... 


ACC 


ES + RT 


Objekttypen (T echnoloqische Objekte) 


TO 


ES + RT 


Versionsinformationen fur Konsistenz zwischen RT, Paketen und Objekten 


ACC 


ES + RT 



[0048] In der Darstellung gemaB FIG 7 werden als OO-Strukturdiagramm exemplarisch mogliche Technologieob- 

35 jekttypen (TO; FIG 6) fur ein Technologiepaket (TP; FIG 6) Kunststoff TPK dargestellt. Bei der Kunststoffbearbeitung 
bzw. -erzeugung benotigt man ublicherweise eine Temperaturregelung und eine Druckregelung. Der Druck, der dann 
auch durch den Druckregler DR geregelt werden muG, wird ublicherweise durch eine einfache Achse A aufgebaut, 
indem die Achse die Materialpaste zusammenpreGt. Fur die Temperaturregelung sind in dtesem Beispiel zwei Tem- 
peraturregler vorgesehen, ein schnellerTemperaturreglerTRS und ein langsamer TemperaturreglerTRL. Wie aus dem 

40 OO-Strukturdiagramm ersichtlich, leiten leiten sich der langsame Temperaturregler TRL und der schnelle Temperatur- 
regler TRS aus dem allgemeinen TemperaturreglerTR ab. Die beiden Temperaturregler TRS und TRL, der Druckregler 
DR und die Achse A werden in dem vorliegenden Technologiepaket Kunststoff durch vier Technologieobjekttypen TO 
reprasentiert, namlich TRS, TRL. DR und A. Durch die Kardinalitat (Ziffer 1 ) wird angedeutet, daf3 bei diesem Beispiel 
genau ein schnellerTRS und ein langsamer Temperaturregler TRL, sowie genau ein Druckregler DR und eine Achse 

45 A verwendet werden. Hinterdem schnellen Temperaturregler TRS kann sich z.B. ein PID-Regler, hinterdem langsamen 
TemperaturreglerTRL kann sich z.B. ein P-Regler verbergen, das sind aber Implementierungsdetails, die einen An- 
wender der Funktionalitaten dieser Technologieobjekttypen im Engineering-System (ES; FIG 1, FIG 4, FIG 8) verwen- 
det, nicht zu interessieren brauchen. Ein Anwender kann somit die Funktionalitaten dieser Technologieobjekttypen 
(TO; FIG 6) im Engineering-System (ES; FIG 1, FIG 4, FIG 8) verwenden, ohne sich urn Implementierungsdetails 

so kummern zu mussen. 

[0049] In der Darstellung gemaB FIG 8 wird gezeigt, daB aus einer Datenquelle D f die Beschreibungsinformationen 
fur Systemvariablen sowie gegebenenfalls Alarme und/oder Sprachbefehle enthalt, uber den Informationspfad 14 an 
den Umsetzer U ubermittelt werden. Der Umsetzer U generiert aus den eingespeisten Daten Parametrierinformationen 
fur das Engineering-System ES4, fur das Ausgabemedium AM und fur das Run-Time-System RTS4. Der Umsetzer U 
55 wird vor der Compilierung der Run-Time-bzw. Engine ring-System-Software aufgerufen. Er erzeugt Sourcen, die dann 
bei der Erzeugung der Run-Time- bzw. Engineering-System -Software compiliert werden. Auf dem informationspfad IS 
< -werden vom Umsetzer U die Parametrierinformationen zum Engineering-System ES4 transferiert. Die vom Umsetzer 
U erzeugten Parametrierinformationen fur die Dokumentation werden uber den Informationspfad 16 an das Ausgabe- 
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medium AM, in FIG 8 dargestellt durch einen Drucker, weitergeleitet. Als Ausgabemedium ist aber auch beispielsweise 
eine Online-Hilfe am Bildschirm vorsteilbar. Die vom Umsetzer generierte Parametrierinformation fur das Run-Time- 
System wird uber den Informationspfad 17 in das Ablaufebenenmodell AE des Run-Time-Systems RTS4 geladen. 
[0050] Der Umsetzer U wird immer dann aufgerufen, wenn er aus der Datenquelle D uber den Informationspfad 14 
neue Parametrierinformation erhalt. Der Umsetzer U erzeugt in einem solchen Fall neue Sourcen fur die Dokumenta- 
tion, das Run-Time-System RTS4 und fur das Engineering-System ES4. 

[0051] Beim Betrieb der Steuerung werden die ins Engineering-System ES4 geladenen Systemvariablen vom Run- 
Time-System RTS4 uber den Informationspfad 18 mit aktuellen Daten des technischen Prozesses versorgt. Der An- 
wender hat die Moglichkeit, bezugnehmend auf den aktuellen Zustand des technischen Prozesses (TP1 , TP2; FIG 1 
bzw. FIG 4) weitere Eingaben am Engineering-System ES4 durchzufuhren, 

[0052] Uberden Informationspfad 19 kann das Run-Time-System RTS4 ein Geratzum maschinennahen Uberwachen 
und Steuern (in FIG 8 dargestellt durch ein Operator Panel OP) mit Informationen (z.B. Alarmen) versorgen. 
[0053] Der Umsetzer U tritt beim Betrieb der Steuerung nicht mehr in Erscheinung. Die Informationspfade 14, 15, 16 
und 17 werden bei der Erzeugung der Steuerungssoftware verwendet, aber nicht beim Betrieb der Steuerung. Beim 
Betrieb der Steuerung werden die Informationspfade 18 und 19 verwendet. 



Patentanspruche 

1 . Universelle Bewegungssteuerung mit Engineering- und Run-Time-System, welche funktionell die klassischen Auf- 
gaben einer speicherprogrammierbaren Steuerung und einer numerischen Steuerung in sich vereinigt, 
dadurch gekennzeichnet, 

daB ein einheitliches Ablaufebenenmodell (AE) dergestalt gebildet ist, daB es mehrere Ablaufebenen unterschied- 
lichen Typs mit unterschiedlicher Prioritat aufweist, wobei von hochster bis niedrigster Prioritat verschiedene An- 
wender- und Systemebenen vorgesehen sind und da3 jeweils Technologiepakete (TP) anwenderseitig in das En- 
gineering- und/oder Run-Time-System (ES1 -ES4, RTS1 -RTS4) ladbarsind, daB eine Datenquelle (D) fur Beschrei- 
bungsinformationen fur Systemvariablen sowie gegebenenfalls Alarme und/oder Sprachbefehle uber einen Um- 
setzer (U) dem Engineering-System (ES1-ES4) Sprachbefehle und/oder Systemvariablen zur Verfugung stellt, 
daB aus dem Run-Time-System (RTS1-RTS4) die Systemvariablen mit aktuellen Daten des technischen Prozes- 
ses (TP1 , TP2) versorgbarsind und daB uber eine Bedienoberflache des Engineering-Systems (ES1-ES4) weitere 
Eingaben anwenderseitig machbar sind. 

2. Universelle Bewegungssteuerung nach Anspruch 1 , 
dadurch gekennzeichnet, 

daB vom Umsetzer (U) aus dem Bestand der Datenquelle (D) relevante Dokumentationsinformationen an ein 
Ausgabemedium (AM) weiterleitbar sind. 

3. Universelle Bewegungssteuerung nach einem der vorstehenden Anspruche, 
dadurch gekennzeichnet, 

daB als Ablaufebenen vorgesehen sind: 

a) eine Lagereglerebene, bestehend aus zugehoriger getakteter Systemebene und Anwenderebene, 

b) eine Interpolatorebene, bestehend aus zugehoriger getakteter Systemebene und Anwenderebene, 

c) eine Event-Systemebene fur reaktionspflichtige Ereignisse, 

d) eine Anwenderebene fur asynchrone Fehler 

e) eine weitere, vom Anwender anforderungsspezifisch frei projektierbare Anwenderebene (FA) fur Alarm- 
und/oder Event- und/oder Regelungs- und/oder sonstige zyklische Tasks, 

f) eine aus der Abfolge von Bewegungssequenzen, freien Zyklen und niederprioren sonstigen Systemtasks, 
gebildete Ebenengruppe fur Hintergrund-Bearbettung, 

wobei die Ablaufebenen a bis e eine Ebenengruppe fur Echtzeit-Bearbeitung bilden. 

4. Universelle Bewegungssteuerung nach einem der vorstehenden Anspruche, 
dadurch gekennzeichnet, 

daB die Technologiepakete (TP) beinhalten: 

a) Code-Teile, die die Regelungsspezifika fur das Runtime-System (RTS1-RTS4) reprasentieren und 

b) einen Konfigurierteil (FWK) der die Zuordnung dieser Code-Teile zu den jeweiligen Systemebenen, sowie 
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deren Bearbeitungsfolge aufweist, wobei 

c) bedarfsweise diese Informationen des Konfigurierteils (FWK) auch an das Engineering-System (ES1-ES4) 
weiterleitbar sind. 

Universelle Bewegungssteuerung nach Anspruch 4, 
dadurch gekennzeichnet, 

daB die Informationen des Konfigurierteils (FWK) eines Technologiepaketes (TP) uber die Datenquelle D und den 
Umsetzer U ins Run-Time-System (RTS1-RTS4) und ins Engineering-System (ES1-ES4) gebracht werden. 

Universelie Bewegungssteuerung nach Anspruch 4 Oder 5, 
dadurch gekennzeichnet, 

daS jedes Technotogiepaket (TP) eine angepaBte Anzahl von Technologieobjekttypen (TO) fur das Run-Time- 
System (RTS1-RTS4) beinhaltet. 

Universelle Bewegungssteuerung nach Anspruch 4, 5 Oder 6, 
dadurch gekennzeichnet, 

daB des weiteren Bedienoberflacheninformationen, insbesondere Bedienparameter (PAR), und/oder Sprachme- 
chanismen (SPR) und/oder Deklarationsteile (ACC) den Code-Teilen zuweisbar sind. 
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